policy(validators): the contractile enforced Deno-only, blocking the Bun ruling - #78
Conversation
…Bun ruling
Owner ruling 2026-08-27: migrate the validators first.
MUST.contractile asserted:
(must "no npm/bun/yarn/pnpm dependencies — Deno only")
which named Bun itself as a prohibited dependency source. The estate-wide Bun
ruling of 2026-08-26 requires package.json + bun.lock, so an agent obeying
.claude/CLAUDE.md in this repo produced a change its own K9 validators reject.
CodeRabbit put it exactly: "These instructions can produce changes that fail
repository validation."
That is why this repo was held out of the fleet rollout. The instruction and
the enforcement disagreed, and the agent had no way to know which won.
Now:
(must "JS deps via Bun — package.json + bun.lock; no npm/yarn/pnpm lockfiles")
The prohibition is preserved where it still applies — competing npm, yarn and
pnpm lockfiles remain banned — and lifted only for Bun, which canon now
mandates. This is a narrowing of the rule to match ratified policy, not its
removal.
With this landed, the Bun policy change for this repo can follow without
producing a self-contradictory state.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Up to standards ✅🟢 Issues
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📜 Recent review details⏰ Context from checks skipped due to timeout. (4)
🔇 Additional comments (1)
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe dependency invariant now permits JavaScript dependencies managed by Bun. Projects must include ChangesDependency policy
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This localized change aligns dependency validation with the required Bun workflow while preserving bans on competing lockfiles; no actionable merge-blocking risk remains after normal checks and review. Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.) Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull Request Overview
The PR successfully updates the .machine_readable/MUST.contractile policy to allow Bun as a dependency manager. Codacy analysis indicates the changes are up to standards with no new quality issues. However, two significant concerns remain:
- Verification Gap: There are no automated tests included to confirm that the validator correctly interprets these natural-language policy updates or that it rejects the prohibited package managers (npm, yarn, pnpm) as intended.
- Lockfile Specification: The current policy explicitly requires
bun.lock, which is a text-based format. This excludes the default binarybun.lockbformat, potentially causing false negatives in automated enforcement for standard Bun projects.
About this PR
- The PR does not include test cases to verify that the updated policy is correctly interpreted and enforced by the validators. There is a risk that the natural-language change may not be understood by the automated agents or tools relying on this file.
Test suggestions
- Verify that a changeset containing a bun.lock and package.json passes the validator.
- Verify that a changeset containing package-lock.json, yarn.lock, or pnpm-lock.yaml is still rejected.
Prompt proposal for missing tests
Consider implementing these tests if applicable:
1. Verify that a changeset containing a bun.lock and package.json passes the validator.
2. Verify that a changeset containing package-lock.json, yarn.lock, or pnpm-lock.yaml is still rejected.
TIP Improve review quality by adding custom instructions
TIP How was this review? Give us feedback
| (must "no new Python files") | ||
| (must "no new Go files") | ||
| (must "no npm/bun/yarn/pnpm dependencies — Deno only") | ||
| (must "JS deps via Bun — package.json + bun.lock; no npm/yarn/pnpm lockfiles") |
There was a problem hiding this comment.
🟡 MEDIUM RISK
Suggestion: Bun's default lockfile is bun.lockb (binary), while bun.lock (text) is the format used in specific configurations. To ensure the policy remains robust and doesn't fail on the default binary format, consider including both extensions.
| (must "JS deps via Bun — package.json + bun.lock; no npm/yarn/pnpm lockfiles") | |
| (must "JS deps via Bun — package.json + bun.lock/bun.lockb; no npm/yarn/pnpm lockfiles") |
Owner ruling 2026-08-27: migrate the validators first.
The collision
.machine_readable/MUST.contractileasserted:(must "no npm/bun/yarn/pnpm dependencies — Deno only")That names Bun itself as a prohibited dependency source. The estate-wide Bun ruling of 2026-08-26 requires
package.json+bun.lock, so an agent obeying.claude/CLAUDE.mdin this repo produced a change its own K9 validators reject.CodeRabbit put it exactly: "These instructions can produce changes that fail repository validation."
This is why the repo was held out of the fleet rollout — the instruction and the enforcement disagreed, and an agent had no way to know which won.
The change
The prohibition is preserved where it still applies — competing npm, yarn and pnpm lockfiles remain banned — and lifted only for Bun, which canon now mandates. A narrowing of the rule to match ratified policy, not its removal.
Sequencing
With this landed, the Bun policy change for this repo (#77) can follow without ever producing a self-contradictory state. That ordering is the point of the ruling: enforcement moves first, then the instruction that depends on it.
🤖 Generated with Claude Code